resolve: Catch "cannot reexport" errors from macros 2.0 better#156014
resolve: Catch "cannot reexport" errors from macros 2.0 better#156014rust-bors[bot] merged 4 commits intorust-lang:mainfrom
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hmm, legitimate |
|
lgtm, but I also wonder why the error in ra was not caught before. Seems it just one simple case of the lint. |
This comment has been minimized.
This comment has been minimized.
|
I'll look what's going on with rust-analyzer. |
|
Reminder, once the PR becomes ready for a review, use |
|
The problem is in So the import itself won't be an error when the |
|
rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead. cc @rust-lang/rust-analyzer |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@rustbot ready |
resolve: Catch "cannot reexport" errors from macros 2.0 better After the macro 2.0 related holes are closed we can report `span_delayed_bug`s in more situations. Merging rust-lang#155945 would make changes in this PR simpler, but that PR will probably have to wait for quite some time. This is a continuation of my import & privacy invariant hardening changes from rust-lang#155257, rust-lang#155213, rust-lang#154149, etc. r? @mu001999
resolve: Catch "cannot reexport" errors from macros 2.0 better After the macro 2.0 related holes are closed we can report `span_delayed_bug`s in more situations. Merging rust-lang#155945 would make changes in this PR simpler, but that PR will probably have to wait for quite some time. This is a continuation of my import & privacy invariant hardening changes from rust-lang#155257, rust-lang#155213, rust-lang#154149, etc. r? @mu001999
…uwer Rollup of 7 pull requests Successful merges: - #156014 (resolve: Catch "cannot reexport" errors from macros 2.0 better) - #156058 (Print HRTB binders before fn qualifiers) - #156172 (Implement a new flag `-Zdisable-fast-paths` in trait solving) - #156184 (Revert "remove `MethodReceiverExpr` special-casing") - #155957 (Revert const hacks and use const closures in std) - #156127 (Update `askama` version to `0.16.0`) - #156183 (Remove duplicate debug assert)
…uwer Rollup of 7 pull requests Successful merges: - #156014 (resolve: Catch "cannot reexport" errors from macros 2.0 better) - #156058 (Print HRTB binders before fn qualifiers) - #156172 (Implement a new flag `-Zdisable-fast-paths` in trait solving) - #156184 (Revert "remove `MethodReceiverExpr` special-casing") - #155957 (Revert const hacks and use const closures in std) - #156127 (Update `askama` version to `0.16.0`) - #156183 (Remove duplicate debug assert)
…uwer Rollup of 7 pull requests Successful merges: - #156014 (resolve: Catch "cannot reexport" errors from macros 2.0 better) - #156058 (Print HRTB binders before fn qualifiers) - #156172 (Implement a new flag `-Zdisable-fast-paths` in trait solving) - #156184 (Revert "remove `MethodReceiverExpr` special-casing") - #155957 (Revert const hacks and use const closures in std) - #156127 (Update `askama` version to `0.16.0`) - #156183 (Remove duplicate debug assert)
Rollup merge of #156014 - petrochenkov:kvak, r=mu001999 resolve: Catch "cannot reexport" errors from macros 2.0 better After the macro 2.0 related holes are closed we can report `span_delayed_bug`s in more situations. Merging #155945 would make changes in this PR simpler, but that PR will probably have to wait for quite some time. This is a continuation of my import & privacy invariant hardening changes from #155257, #155213, #154149, etc. r? @mu001999
After the macro 2.0 related holes are closed we can report
span_delayed_bugs in more situations.Merging #155945 would make changes in this PR simpler, but that PR will probably have to wait for quite some time.
This is a continuation of my import & privacy invariant hardening changes from #155257, #155213, #154149, etc.
r? @mu001999